Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000194_owner-urn-ietf _Fri Nov 22 14:42:06 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA24537 for urn-ietf-out; Fri, 22 Nov 1996 14:42:06 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA24532 for <[e-mail]>; Fri, 22 Nov 1996 14:42:03 -0500
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA25620  (mail destined for [e-mail]); Fri, 22 Nov 96 14:42:02 -0500
Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id OAA21503; Fri, 22 Nov 1996 14:42:01 -0500
Message-Id: <[e-mail]>
From: [e-mail] (Leslie Daigle)
Date: Fri, 22 Nov 1996 14:42:00 -0500
In-Reply-To: "Ryan Moats"'s message as of Nov 22, 10:41
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Ryan Moats" <[e-mail]>,
        "URN mailing list" <[e-mail]>
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (Leslie Daigle)
Errors-To: [e-mail]

This touches on something I asked Ryan about in the draft, and wanted to
bring up here.

In reading through the recent thread on character sets and URNs (admittedly,
slightly out of step with real-time), it seemed to come to a reasoned
and reasonable conclusion about handling character sets other than US-ASCII
in URNs.  I didn't feel that this was completely represented in the
syntax draft, although I'm not sure whether it was because my reading
of the thread was at fault.

[Ryan brought up:]
> 4. human readability for new namespaces: MUST/SHOULD?

This is in reference to the paragraph, in the syntax draft:

      Some existing name spaces that have the properties of the URN-space
      contain some human-significant components, and these exist in a wide
      variety of languages.  However, URNs are NOT intended to convey
      information that is significant to humans.  While the translation
      rule in section 2.2 is provided for existing namespaces, new
      namespaces, as part of their registration documentation, MUST define
      a discipline for assigning new URNs that does not simplify the
      generation of human-significant names.


The way I read this, the only thing the syntax draft is recognizing is
that there may be existing namespaces that have things that happen to
be human-readable, and these may be in character sets other than US-ASCII,
so UTF-8 is proposed as a mechanism of handling these anomalies -- but
that these namespaces should ensure that future names assigned should not
suffer from human-readability.  (Admittedly, a "strong" reading of the
statement, but I'm trying to illustrate the point).

I just don't see the point of such a statement.

The syntax draft defines how to formally express a URN -- in US-ASCII or
UTF-8.  Period.

What things a namespace-proposer chooses to use in their namespace is
not relevant, as long as they can be carried in this syntax, and otherwise
meet the requirements of namespaces (uniqueness of names, etc).  So,
if someone proposes a namespace that happens to be human-friendly (_whatever_
that means!) in spite of meeting all these requirements, cool!

What was intended in the charter was to avoid having the syntax and handling
mechanisms' design _driven_ by a need to keep things "human-friendly"
(e.g., shorter than URLs, no funny punctuation, whatever).

Once we've settled on a syntax and handling mechanisms, we have nothing
further to say about what people do within those constraints.

I bring all of this up because it is not clear to me that particular paragraph
adequately represented what _seemed_ to be consensus on the matter on
the list.

If that is the case, I would propose the following change to the syntax
draft:

> 3. Support of existing legacy naming systems and new naming systems

   > URN-aware applications MAY accept as input other resource identifiers
   > from existing legacy namespaces.  If such identifiers contain
   > characters that are not members of the URN character set specified in
   > section 2.2, the identifier MUST be translated to canonical format as
   > discussed in section 2.2.
>
   > Some existing name spaces that have the properties of the URN-space
   > contain some human-significant components, and these exist in a wide
   > variety of languages.  However, URNs are NOT intended to convey
   > information that is significant to humans.  While the translation
   > rule in section 2.2 is provided for existing namespaces, new
   > namespaces, as part of their registration documentation, MUST define
   > a discipline for assigning new URNs that does not simplify the
   > generation of human-significant names.

 would become:


3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as a
   URN-namespace and fulfills the criteria of URN-namespaces must
   be expressed in this syntax.  If names in these spaces contain
   characters other than those defined for the URN character set,
   they must be translated into canonical format as discussed in
   section 2.2.


Well, it's not the most inspired wording, but can people live with
this?

Leslie.

--

----------------------------------------------------------------------------

  "The light at the end of the tunnel             Leslie Daigle
     is often the blindingly obvious..."          Vice President, Research
                                                  Bunyip Information Systems
                      -- ThinkingCat              [phone]
                                                  [e-mail]
----------------------------------------------------------------------------